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Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including tlie fee set 
forth in 37 CFR 1 .17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 

forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 
01/18/2008 has been entered. 

DETAILED ACTION 

2. Claims 1-5, 11, 13, 14, 18-24 and 31-42 are pending and have been examined. 

Response to Arguments 

3. Applicant's arguments filed 01/18/2008 have been fully considered but they are 
not persuasive. 

In response to applicant's argument (Remarks section A) that McCoskey (US 
PGPUB 2003/0028889) fails to disclose providing video from a plurality of incompatible 
and non-interoperable video on demand systems, the examiner respectfully disagrees. 
McCoskey clearly teaches an aggregator (Fig. 4: 201) which receives content from a 
plurality of diverse sources ([0045]) and reformats the content into a format suitable for 
delivery to the user terminals ([0053]). Therefore, content sources of McCoskey are 
clearly "incompatible and non-interoperable" or there would be no reason for the 
aggregator to collect, reformat and store the content already stored on the remote 
sources ([0046]). 
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Applicant furtlier argues tliat "tine examiner acknowledges ... McCoskey fails to 
disclose communicating in multiple protocols". As discussed in the previous office 
action (Final Rejection dated 10/18/2007) the acknowledgment referred to was an 
acknowledgment that McCoskey does not specifically disclose receiving lists of 
currently available content in different protocols not "McCoskey fails to disclose 
communicating in multiple protocols". 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

5. Claims 1-5, 11, 13, 14, 18-24 and 37 are rejected under 35 U.S.C. 103(a) as 

being unpatentable over McCoskey et al. (US Patent Application Publication 

2003/0028889), McCoskey, in view of Ogawa et al. (US Patent 6,314,571), Ogawa. 

Consider claim 1, McCoskey clearly teaches a system providing video on 
demand services from a plurality of incompatible and non-interoperable VOD 
systems. (Fig. 1: The system 200 provides VOD services from a plurality of 
incompatible devices, [0045]) 

receiving a request from a receiver station for all currently available VOD 
assets; (A programming search request is created and sent by the 
user, [0086]. The search criteria may be set so as to return all 
available content.) 

transmitting to each of the plurality of incompatible VOD systems a 
request for a respective list of all currently available VOD assets; (Fig. 4: 
Search engine server 350 periodically requests information on all 
available programming from the remote sources, [0065]) 
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aggregating tlie translated lists of all currently available VOD assets to 
form a combined list of available VOD assets, the combined list of 
available VOD assets being adapted to be compatible with a plurality of 
receiver stations. (Fig. 10: Aggregator local database 501 contains the 
remote content database 261 which stores a catalog of all content 
stored in each of the remote databases, [0079] -[0080].) 

McCoskey further teaches receiving all currently available VOD assets, in 
response to the request for the assets. (Remote content crawler 356 retrieves 
all information about all content not previously logged, [0065]) 

However, McCoskey does not explicitly teach each received list being formatted 
in a unique protocol and translating the received lists into a generic protocol. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 



Consider claim 2, McCoskey and Ogawa, combined as in claim 1 , clearly teach, 
after receiving a request for content from a user (Fig. 15b: In step 712 the user 
requests content then in step 715 the request is sent to the aggregator 201, 
[0103] McCoskey.), performing the following steps: 

identifying which VOD system is associated with the requested VOD asset 
via the received list of all currently available VOD assets from one of the 
plurality of incompatible VOD systems; (Fig. 16a: In step 759 the 
metadata associated with the requested content is analyzed to 
determine the storage location of the content, [0106] McCoskey.) 

transmitting, to the identified VOD system, a compatible request for the 
VOD asset; (Fig. 16b: In step 762 the remote content server 204 is 
notified of the request, [0107] McCoskey.) 
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receiving tlie requested VOD asset from the identified VOD system; (Fig. 
17a: In step 804 the requested content is transmitted to the 
aggregator 201, [0109] McCoskey.) 

adapting tlie received VOD asset to be compatible witli tlie requesting 
receiver station; (Fig. 17b: In steps 812 and 813 the content is 
formatted to the required format, [0111] McCoskey.) 

transacting for the requested VOD asset with the requesting receiver 
station and the identified VOD system. (Fig. 17c: If billing or fees are 
applicable routine 830 enters the user, content meta data and 
content provider into the billing process 900, [0117 McCoskey.]) 



Consider claims 3, 14, 21, 22, 23, 24, 33, 34, 35 and 36, McCoskey and Ogawa, 
combined as in claims 1 , 13, 20 and 32, clearly teach the requested VOD asset 
may be a video program, audio program, electronic book (text) or multimedia 
(graphic). ([0043] McCoskey) 

Consider claim 4, McCoskey and Ogawa, combined as in claim 1 , clearly teach 
each VOD system contains an asset management system for managing 
respective assets (Fig. 16b: The remote servers use routine 763 to control 
the dissemination of the content, [0107] McCoskey.) and a business 
management system for managing transactions. (Aggregator 201 negotiates 
fees with content providers and distributes compensation to the content 
providers, [0123] McCoskey.) The VOD asset management system is 
communicated with via an asset gateway. (Fig. 4: Content acquisition server 
400 requests content from the remote servers, [0060] McCoskey.) The 
business management system is transacted with using a transaction gateway. 
(Fig. 10: Content fee and copyright billing server 507 communicates with 
the business management system of the content providers, [0123] 
McCoskey.) 

Consider claim 5, McCoskey and Ogawa, combined as in claim 1 , clearly teach 
providing the desired asset to the receiver using either digital storage command 
and control or real time streaming protocol. (The content may be streamed to 
the user or delivered and stored by the user for later playback, [0116] 
McCoskey.) 



Consider claim 11, McCoskey clearly teaches a system providing video on 
demand services from a plurality of incompatible and non-interoperable VOD 
systems. (Fig. 1: The system 200 provides VOD services from a plurality of 
incompatible devices, [0045]) 
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transmitting to eacli of the plurality of incompatible VOD systems a 
request for a respective list of all currently available VOD assets; (Fig. 4: 
Search engine server 350 periodically requests information on all 
available programming from the remote sources, [0065]) 

aggregating the translated lists of all currently available VOD assets to 
form a combined list of available VOD assets, the combined list of 
available VOD assets being adapted to be compatible with a plurality of 
receiver stations. (Fig. 10: Aggregator local database 501 contains the 
remote content database 261 which stores a catalog of all content 
stored in each of the remote databases, [0079] -[0080].) 

receiving a request from a receiver station for a VOD asset; (Fig. 15b: In 
step 712 the user requests content then in step 715 the request is 
sent to the aggregator 201, [0103] McCoskey.) 

in response to a request from a receiver station for a VOD asset, performing the 
following steps: 

identifying which VOD system is associated with the requested VOD asset 
via the received list of all currently available VOD assets from one of the 
plurality of incompatible VOD systems; (Fig. 16a: In step 759 the 
metadata associated with the requested content is analyzed to 
determine the storage location of the content, [0106] McCoskey.) 

transmitting, to the identified VOD system, a compatible request for the 

VOD asset; (Fig. 16b: In step 762 the remote content server 204 is 

notified of the request, [0107] McCoskey.) 



receiving the requested VOD asset from the identified VOD system; (Fig. 
17a: In step 804 the requested content is transmitted to the 
aggregator 201, [0109] McCoskey.) 

adapting the received VOD asset to be compatible with the requesting 
receiver station; (Fig. 17b: In steps 812 and 813 the content is 
formatted to the required format, [0111] McCoskey.) 

transacting for the requested VOD asset with the requesting receiver 
station and the identified VOD system. (Fig. 17c: If billing or fees are 
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applicable routine 830 enters the user, content meta data and 
content provider into the billing process 900, [0117] McCoskey.) 

McCoskey further teaches receiving all currently available VOD assets, in 
response to the request for the assets. (Remote content crawler 356 retrieves 
all information about all content not previously logged, [0065]) 
However, McCoskey does not explicitly teach each received list being formatted 
in a unique protocol and translating the received lists into a generic protocol. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 

Consider claims 13, 20 and 32, McCoskey and Ogawa, combined as in claims 
11,19 and 31 , clearly teach each VOD system includes a business management 
system. (Aggregator 201 negotiates fees with content providers and 
distributes compensation to the content providers, [0123] McCoskey.) 
When a program is received at the receiving station an event is recorded 
showing a purchase of that program. (Fig. 10: When content is downloaded 
the content delivery server 450 logs the event with database administrator 
502, [0126] McCoskey.) The purchase event is then transmitted from the VOD 
gateway to the corresponding business management system. (Fig. 10: Content 
fee and copyright billing server 507 transmits compensation to the content 
providers, [0123] McCoskey.) 



Consider claims 18, 19 and 31, McCoskey clearly teaches a system, having a 
transmitting station including a gateway server (Fig. 2 Aggregator 201) and a 
receiving station including a generic client (Fig. 2 Set top terminal 206), 
providing video on demand services from a plurality of incompatible and non- 
interoperable VOD systems. (Fig. 1: The system 200 provides VOD services 
from a plurality of incompatible devices, [0045] - [0046]) Each VOD system 
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having an asset management system. (Fig. 16b: The remote servers use 
routine 763 to control the dissemination of the content, [0107] l\/lcCosl(ey.) 

receiving a request from a receiver station for all currently available VOD 
assets; (A programming search request is created and sent by the 
user, [0086]. The search criteria may be set so as to return all 
available content.) 

transmitting a request from said VOD gateway to said first and second 
VOD asset management system for a first and second list of all currently 
available VOD assets stored in said first and second VOD system. (Fig. 4: 
Search engine server 350 periodically requests information on all 
available programming from the remote sources, [0065]) 

aggregating the first and second translated lists of all currently available 
VOD assets to form a combined list of available VOD assets. (Fig. 10: 
Aggregator local database 501 contains the remote content database 
261 which stores a catalog of all content stored in each of the remote 
databases, [0079] -[0080].) 

transmitting from the receiving station to the gateway server a request for 
a list of VOD assets. (Fig. 13a: Routine 613 sends a search request to 
the aggregator 201, [0089].) 

transmitting the combined list of VOD assets from the gateway to the 
receiver. (Fig. 14b: Routine 671 sends the list of content to the user 
terminal, [0100].) 

receiving a request from a receiver station for a VOD asset (Fig. 15b: In 
step 712 the user requests content then in step 715 the request is 
sent to the aggregator 201, [0103] McCoskey.) 

determining which VOD server contains the requested content via the 
received first and second lists of all available content (Fig. 16a: In step 
759 the metadata associated with the requested content is analyzed 
to determine the storage location of the content, [0106] McCoskey.) 

foHA/arding the request to the specified first or second VOD server (Fig. 

16b: In step 762 the remote content server 204 is notified of the 



request, [0107] McCoskey.) 
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receiving tlie requested VOD asset from the identified VOD system; (Fig. 
17a: In step 804 the requested content is transmitted to the 
aggregator 201, [0109] McCoskey.) 

IVIcCoskey furtlier teaclies receiving all currently available VOD assets, in 
response to the request for the assets. (Remote content crawler 356 retrieves 
all information about all content not previously logged, [0065]) 

However, McCoskey does not explicitly teach each received list being formatted 
in a unique protocol and translating the received lists into a generic protocol. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 

Consider claim 37, McCoskey clearly teaches a video on demand gateway 
enabling the delivery of VOD services to subscriber equipment from a plurality of 
incompatible and non-interoperable VOD systems. (Fig. 1 : The system 200 
provides VOD services to subscriber terminals from a plurality of 
incompatible devices, [0045]) 
The VOD gateway comprising: 

an asset gateway, for providing a unified list of VOD assets from the 
received lists of all currently available VOD assets. (Remote content 
crawler 356 retrieves all information about all content not previously 
logged, [0065]. Fig. 10: Aggregator local database 501 contains the 
remote content database 261 which stores a catalog of all content 
stored in each of the remote databases, [0079]-[0080].) 

a transaction gateway, for conforming communications into the 
appropriate format from the subscriber to the appropriate VOD system and 
from the VOD system to the subscriber. (Fig. 15b user download 
request is sent to the aggregator. The aggregator then translates 
and routes the request to the remote server. Fig. 16b step 762. The 
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remote server then transmits the requested content to the 
aggregator, Fig. 17a step 804. The content is then reformatted, Fig. 
17b step 813, and transmitted to the user terminal. Fig. 17c step 826.) 

However, McCoskey does not explicitly teach translating received lists, each in a 
unique protocol, from each of the incompatible VOD systems. 

In an analogous art Ogawa, which discloses a system for collecting information 
stored in separate systems and transmitting a combined list of all assets, clearly 
teaches receiving the lists in different protocols and translating the lists into a 
generic protocol. (Fig. 6: The EPG data collection and delivery center 1 
receives EPG data from a plurality of sources in different formats and data 
converting section 14 converts the data into a generic format and stores 
the data in the transmitting-data storing section 131, column 10 lines 53- 
67.) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey by receiving 
the lists in different formats and translating them into a generic format, as taught 
by Ogawa, for the benefit of providing updated information to the users without 
changing individual system configurations (see column 2 lines 31-42 Ogawa). 



6. Claims 38-41 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
McCoskey et al. (US Patent Application Publication 2003/0028889) in view of 
Ogawa et al. (US Patent 6,314,571), as applied to claims 1 and 37 above, and further 
in view of Bowman-Amuah (US Patent 6,434,568). 



Consider claim 38, McCoskey and Ogawa, combined as in claim 37, clearly 
teach the asset gateway communicating with the transaction gateway (Fig. 16a: 
The users request is transferred to routine 762 where it is encrypted for 
communication to the remote servers, [0107] McCoskey.) and an asset data 
manager which communicates with each asset management system via a 
respective interface program. (Fig. 7: Search engine server 350 
communicates with each VOD system to retrieve content information, 
[0065] McCoskey. The use of respective interface programs is inherently 
disclosed in order for search engine server to communicate with the 
incompatible remote servers.) 
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However, McCoskey and Ogawa do not explicitly teach the use of a servlet and 
application programming interfaces. 

In an analogous art Bowman-Amuah, which discloses a system for transmission 
of data across a network, clearly teaches the use of a servlet (Java applet, 
ActiveX, column 15 lines 42-57) and application programming interfaces, 
(column 52 lines 49-63) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey and Ogawa by 
utilizing a servlet or API, as taught by Bowman-Amuah, for the benefit of 
providing a more secure, architecture neutral, platform independent, portable, 
flexible and easier to develop system (see column 15 lines 50-57 and column 52 
lines 52-56 Bowman-Amuah). 

Consider claim 39, McCoskey and Ogawa, combined as in claim 37, clearly 
teach the transaction gateway communicating with each business management 
system (BMS) via a respective BMS program. (Fig. 10: Content fee and 
copyright billing server 507 communicates with the business management 
system of the content providers, [0123] McCoskey.) 

However, McCoskey and Ogawa do not explicitly teach the use of application 
programming interfaces. It would have been obvious to modify the system of 
McCoskey and Ogawa with Bowman-Amuah as shown in claim 38. 

Consider claim 40, McCoskey and Ogawa, combined as in claim 37, clearly 
teach the VOD gateway includes a database for storing client transaction 
information. (Fig. 11 User database server 511, [0079] McCoskey) 



Consider claim 41, McCoskey and Ogawa, combined as in claim 37, clearly 
teach a session gateway communicating with each VOD manager via respective 
session interface programs. (Fig. 16b: Routine 762 routes the request for the 
content to the correct remote server, [0107] McCoskey. The use of 
respective session interface programs is inherent, see claim 38.) 

However, McCoskey and Ogawa do not explicitly teach the use of application 
programming interfaces. It would have been obvious to modify the system of 
McCoskey and Ogawa with Bowman-Amuah as shown in claim 38. 

7. Claim 42 is rejected under 35 U.S.C. 103(a) as being unpatentable over 

McCoskey et al. (US Patent Application Publication 2003/0028889) in view of 
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Ogawa et al. (US Patent 6,314,571) in view of Bowman-Amuah (US Patent 
6,434,568), as applied to claim 41 above, and further in view of Burkhart (US Patent 
Application Publication 2002/0006116). 



Consider claim 42, McCoskey, Ogawa and Bowman-Amuah, combined 
as in claim 41 , clearly teach the VOD gateway of claim 41 . 

However, McCoskey, Ogawa and Bowman-Amuah do not explicitly teach each 
VOD manager determines channel parameters associated with a subscriber 
request. 

In an analogous art Burkhart, which discloses a system aggregation of content, 
clearly teaches each VOD manager determines channel parameters associated 
with a subscriber request. ([0027], [0030], [0032] lines 1-21) The session 
gateway communicating VOD channel parameters to the subscriber using one of 
Session Resource Management ([0030], [0032] lines 7-15) and Session set up 
protocol. ([0027], [0030], [0032] lines 33-45) 

Therefore, at the time the invention was made, it would have been obvious to 
one with ordinary skill in the art to modify the system of McCoskey, Ogawa and 
Bowman-Amuah by determining channel parameters associated with subscriber 
requests and communicating them via SRM or SSP, as taught by Burkhart, for 
the benefit of providing users with information needed to obtain the content (see 
[0032] Burkhart). 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to JOHN R. SCHNURR whose telephone number is 
(571)270-1458. The examiner can normally be reached on Monday - Friday, 8:00am to 
5:30pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Christopher Grant can be reached on (571) 272-7294. The fax phone 
number for the organization where this application or proceeding is assigned is 571- 



273-8300. 
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